Design Systems Roadmap
Step 1: Establish core team & collaboration
Checklist
- Establish a stable team that is detached from daily product development pressure. At least have a 'product owner' to communicate with products and hopefully also a 'lead developer' to help in integrating workflows to current ways of workingl
- Get buy-in from design and architecture leadership
- Map products & projects maturity, which (ront-end technologies to be serve. Map products and their interest towards DS initiative. Which projects are no-brainers to collaborate with? Which projecsts need some more warming up?
- Map key people (developers, designers, product manager) to collaborate with. Agree on how these people should be served (Typically Figma design kit for Design team, Design tokens and React components for dev team)
- Make appropriate announcements, let everyone know you are working on a design system. Let 'em know this is not a development project, but more like internal collaboration projec.
- Establish cadence with key people.
- Core team should probably join design systems slack http://design.systems/slack/
Stuff to read:
- Design system teams
- Nathan Curtis - System of Systems (Video)
- A Design System isn’t a Project. It’s a Product, Serving Products.
- https://varya.me/blog/design-systems-review/
Step 2: Start small
Checklist
- Create a dev and testing and publishing pipeline
- Make some part of the design installable as a dependency. via NPM. The idea is to crate a versioned component system, that can be installed as an dependency. A good candidate is to start with Design tokens.
- Work with key projects to use that small reusable part in their project. E.g. with design Tokens, remove design variables from code base and install it as dependency instead.
Stuff to read:
3: Component library + Design Toolkit
Checklist
-
Create a documentation portal for communicating and documenting design system. It probably is a good idea to build both internal and external access, since sooner or later the design system will have 'internal only' parts, but you usually still want large parts of the system to be accessible to external agencies and consultants. Depending on the amoun to design documentation, you might want to go with static site generator, or build it on top of styleguide generators like storybook or pattern lab. Simple styleguide generators are often are lacking in how to document design tokens and things that are not components.
-
Add basic components like form elements, buttons, links. Use the 'main product' or chosen web component library. If there is no such thing, just go with HTML+CSS, and leave the implementation of JS components for later.
-
Create a design toolkit that is in sync with the components, and uses the same naming and terminology.
-
Publish the website and let people know. This might not yeat be useful for product teams, but it's good to make some noise.
-
You should work with few projects to refactor their UI at this point to use the components installed as npm dependency, to get feedback on their use in real projects.
-
Eleventy Is a good tool for rolling your own Design system documentation portal
-
Zeroheight is a good tool to get started fast.
Step 4: Establish a contribution model
Checklist
-
Create a contribution model for both designers and developers to get their patterns into the pattern library. Document and communicate clear steps for contributing. For example:
- Contact Design systems team in Slack channel for help
- Update the master sketch files
- Create a branch on pattern library, and submit a pull request
-
This is a good time to remind product managers / project managers that this is a collaboration effort, not a software development project! The developers working in product projects should be actively building common and the developers working in product projects should have permission to work on common components too, even though it might be more work initially. Everyone loves reusability, but in practice it seems to be hard to get people off their daily grind.
-
"Get free bugfixes for your components!"
-
"Develop one component, get 20 free!"
-
Create Posters, presentations, laptop stickers, awards, hackathons. Hand out candies!
-
Try to get Design system component work visible in the ticketing system, such as Jira. E.g a Design system components should be tasks in product backlogs, that product developers can work on. The core team is there to help and keep the standards up and keep the design and dev work in sync, not to do everything by themselves.
Stuff to read
Step 5: Dogfooding
- Create a simple demo app for presenting the components, to make sure that people who develop the components have to use them somewhere too.
- Create a product starter repo that uses the components with other components. (E.g this is how to use Main navigation component with React router component).
- Start writing release notes and migration guides.
- Create support channel for feedback, bug reporting and work prioritization channels for core team work.
- Start discussiona about work rotation among product teams. To get DS-minded developers in the teams that need them. And to get fresh eyes in developing the DS.
Step 6: Work as usual
- By now, you should have more than enough feature requests for new components / patterns / js libraries. (Unless you skipped the part about collaboration)
- Some good tools to keep in hand is
- Celebrating the milestones like release of 1.0 version
- Organize internal events: Training, Hackathons, internal presentations
- Stuff to read: How design systems fail: https://adactio.com/journal/14041
- Build bigger blocks, reusable features
- Do hackathons to get time-limited developers and designers to participates